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Abstract 


Many Internet Engineering Task Force (IETF) protocols make use of 
commonly defined values that are passed in messages or packets. To 
ensure consistent interpretation of these values between independent 
implementations, there is a need to ensure that the values and 
associated semantic intent are uniquely defined. The IETF uses 
registry functions to record assigned protocol parameter values and 
their associated semantic intentions. For each IETF protocol 
parameter, it is current practice for the IETF to delegate the role 
of Protocol Parameter Registry Operator to a nominated entity. This 
document provides a description of, and the requirements for, these 
delegated functions. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Architecture Board (IAB) 
and represents information that the IAB has deemed valuable to 
provide for permanent record. Documents approved for publication by 
the IAB are not a candidate for any level of Internet Standard; see 
Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6220. 
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1. Overview 


Many IETF protocols make use of commonly defined values that are 
passed within messages or packets. To ensure consistent 
interpretation of these values between independent implementations, 
there is a need to ensure that the values and associated semantic 
intent are uniquely defined. The IETF uses registries to record each 
of the possible values of a protocol parameter and their associated 
semantic intent. These registries, their registration policy, and 
the layout of their content are defined in the so-called "IANA 
Considerations" sections of IETF documents. 


The organizational separation between the IETF and its Registry 
Operators parallels ones that are fairly common among standards 
development organizations (SDOs) although less common among 
technology consortia and similar bodies. These functions have been 
Separated into different organizations for several reasons. They 
include dealing with administrative issues, addressing concerns about 
maintaining an adequate distance between basic policy and specific 
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allocations, and avoiding any potential conflicts of interest that 
might arise from commercial or organizational relationships. For 
example, most ISO and ISO/IEC JTC1 standards that require 
registration activities specify a Registration Authority (RA) or 
Maintenance Agency (MA) that, in turn, control the actual 
registration decisions. The databases of what is registered for each 
standard may then be maintained by a secretariat or database function 
associated with the RA or MA or, less frequently, by the secretariat 
of the body that created and maintains the standard itself. 


This structural separation of roles exists within several places in 
the IETF framework (e.g., the RFC Editor function). The Internet 
Architecture Board (IAB), on behalf of the IETF, has the 
responsibility to define and manage the relationship with the 
Protocol Registry Operator role. This responsibility includes the 
selection and management of the Protocol Parameter Registry Operator, 
as well as management of the parameter registration process and the 
guidelines for parameter allocation. 


As with other SDOs, although it may delegate authority for some 
specific decisions, the IETF asserts authority and responsibility for 
the management of all of its protocol parameters and their 
registries, even while it generally remains isolated from the 
selection of particular values once a registration is approved. This 
document describes the function of these registries as they apply to 
individual protocol parameters defined by the IETF Internet Standards 
Process [RFC2026] to allow for an orderly implementation by the 
Internet Administrative Oversight Committee (IAOC), and others as 
needed, under guidance from the IAB. 


Below we provide a description of the requirements for these 
delegated functions, which the IETF traditionally refers to as the 
Internet Assigned Numbers Authority (IANA) function. 


2. Roles and Responsibilities Concerning IETF Protocol Parameter 
Registries 


The IETF's longstanding practice is to outsource the management and 
implementation of some important functions (e.g., [RFC5620]). The 
protocol parameter registry function falls into this category of 
outsourced functions, and what follows here is the description of the 
roles and responsibilities with respect to the registration of IETF 
protocol parameters. 


Specifically, this document describes the operation and role of a 
delegated IETF Protocol Parameter Registry Operator, to be selected 
and administered by the IETF Administrative Support Activity (IASA) 
[RFC4071]. While there is generally a single Protocol Parameter 
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Registry Operator, additional Operators may be selected to implement 
specific registries, and that has been done occasionally. Having a 
single Operator facilitates coordination among registries, even those 
that are not obviously related, and also makes it easier to have 
consistency of formats and registry structure, which aids users of 
the registries and assists with quality control. 


Many protocols make use of identifiers consisting of constants and 
other well-known values. Even after a protocol has been defined and 
deployment has begun, new values may need to be assigned (e.g., fora 
new option type in DHCP, or a new encryption or authentication 
algorithm for IPsec). To ensure that such quantities have consistent 
values and interpretations in different implementations, their 
assignment must be administered by a central authority. For IETF 
protocols, that role is provided by a delegated Protocol Parameter 
Registry Operator. For any particular protocol parameter there is a 
single delegated Registry Operator. 


2.1. Protocol Parameter Registry Operator Role 


The IETF Protocol Parameter Registry function is undertaken under the 
auspices of the Internet Architecture Board. 


The roles of the Protocol Parameter Registry Operator are as follows: 
o Review and Advise 


* A Registry Operator may be requested to review Internet-Drafts 
that are being considered by the Internet Engineering Steering 
Group (IESG), with the objective of offering advice to the IESG 
regarding the contents of the "IANA Considerations" section, 
whether such a section, when required, is clear in terms of 
direction to the Registry Operator, and whether the section is 
consistent with the current published Registry Operator 
guidelines. 


o Registry 

* To operate a registry of protocol parameter assignments. 

* The delegated Registry Operator registers values for Internet 
protocol parameters only as directed by the criteria and 
procedures specified in RFCs, including Proposed, Draft, and full 
Internet Standards, Best Current Practice documents, and other 


RFCs that require protocol parameter assignment. 


If values for Internet protocol parameters were not specified, or 
in case of ambiguity, the Registry Operator will continue to 
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assign and register only those protocol parameters that have 
already been delegated to the Operator, following past and 
current practice for such assignments, unless otherwise directed 
in terms of operating practice by the IESG. In the case of 
ambiguity, the Registry Operator is expected to identify the 
ambiguity to the IAB or IESG as appropriate and either suggest 
better text or ask the appropriate parties for clarification. 


* For each protocol parameter, the associated registry includes: 


+ a reference to the RFC document that describes the parameter 
and the associated "IANA Considerations" concerning the 
parameter, and 


+ for each registration of a protocol parameter value, the source 
of the registration and the date of the registration, if the 
date of registration is known, and 


+ any other information specified as being included in the 
registration data in the RFC document that describes the 
parameter. 


+ If in doubt or in case of a technical dispute, the Registry 
Operator will seek and follow technical guidance exclusively 
from the IESG. Where appropriate, the IESG will appoint an 
expert to advise the Registry Operator. 


* The Registry Operator will work with the IETF to develop any 
missing criteria and procedures over time, which the Registry 
Operator will adopt when so instructed by the IESG. 


* Unless special circumstances apply to subsets of the data and 
specific rules are established by IETF consensus, each protocol 
parameter registry operates as a public registry, and the 
contents of the registry are openly available to the public, 
on-line and free of charge. 


* The Registry Operator assigns protocol parameter values in 
accordance with the policy associated with the protocol 
parameter, such as "First Come First Served" or "Expert Review" 
[RFC5226]. 


o Mailing Lists 
* The Registry Operator maintains public mailing lists as specified 
in IANA Considerations [RFC5226]. Such lists are designated for 


the purpose of review of assignment proposals in conjunction with 
a designated expert review function. In addition, each Protocol 
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Parameter Registry Operator should maintain a mailing list that 
enables the registry staff of the Registry Operator to be 
contacted by email. 


o Liaison Activity 


* The Registry Operator will nominate a liaison point of contact. 
The Registry Operator, through this liaison, may be requested to 
provide advice to the IESG on IETF protocol parameters as well as 
the "IANA Considerations" section of each Internet-Draft that is 
being reviewed for publication as an RFC. Where appropriate the 
IESG will appoint an expert to advise the Registry Operator. 


o Reporting 


* The Registry Operator will submit periodic reports to the IAB 
concerning the operational performance of the registry function. 
As an example of the requirements for such reports, the reader is 
referred to a supplement [IAOC_SUPP] to the "Memorandum of 
Understanding Concerning the Technical Work of the Internet 
Assigned Numbers Authority" [RFC2860] that provides service level 
agreement (SLA) guidelines under which ICANN, the current 
protocol parameter registry, must operate. 


* At the request of the chair of the IETF, IAB, or IAOC, the 
Registry Operator will undertake periodic reports to IETF Plenary 
meetings concerning the status of the registry function. 


* The Registry Operator will publish an annual report describing 
the status of the function and a summary of performance 
indicators. 


o Intellectual Property Rights and the Registry Operator 


* All assigned values are to be published and made available free 
of any charges. 


* The assignment values may be redistributed without modification. 
* Any intellectual property rights of the IETF protocol parameter 
assignment information, including the IETF protocol parameter 


registry and its contents, are to be held by the IETF Trust 
[RFC4748]. 
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2.2. IAB Role 


An Operator of an IETF protocol parameter registry undertakes the 
role as a delegated function under the authority of the IAB. 


The IAB has the responsibility to review the current description of 
the registry function from time to time and direct the Registry 
Operator to adopt amendments relating to its role and mode of 
operation according to the best interests of the IETF and the 
Internet community in general. 


The IAB has the responsibility to appoint an organization to 
undertake the delegated functions of the Protocol Parameter Registry 
Operator for each IETF protocol parameter. Specifically, the IAB 
defines the role and requirements for the desired functions. The 
IAOC is responsible for identifying a potential vendor, and once 
under agreement, managing the various aspects of the relationships 
with that vendor. To be clear, the IAB is in the deciding role 
(e.g., for appointment and termination), but must work in close 
consultation with the IAOC. 


The IAB has the responsibility to determine the terms and conditions 
of this delegated role. Such terms and conditions should ensure that 
the registry operates in a manner that is fully conformant to the 
functions described in this document. In addition, such terms and 
conditions must not restrict the rights and interests of the IETF 
with respect to the registry contents and maintenance. 


2.3.  IESG Role 


The IESG is responsible for the technical direction regarding entries 
into IETF protocol parameter registries and maintaining the policies 
by which such technical directions are given. Technical direction 
itself is provided through the adoption of directives within the 
"TANA Considerations" section of IETF Stream RFCs or through stand- 
alone "IANA Considerations" RFCs. 


The IESG shall verify that Internet-Drafts that are offered for 
publication as IETF Stream RFCs [RFC4844] include "IANA 
Considerations" sections when needed, and that "IANA Considerations" 
sections conform to the current published guidelines. 


Since technical assessment is not generally a responsibility of the 
Registry Operator, as part of providing the technical direction the 
IESG is responsible for identifying the technical experts that are 
required to, where appropriate, review registration requests or 
resolve open technical questions that relate to the registration of 
parameters. 
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At its discretion, the IESG will organize the liaison activities with 
the Registry Operator’s liaison point of contact so as to facilitate 
clear communications and effective operation of the registry 
function. 


2.4. Role of the IETF Trust 


The IETF Trust [RFC4748] was formed to act as the administrative 
custodian of all copyrights and other intellectual property rights 
relating to the IETF Standards Process, a function that had 
previously been performed by the Internet Society (ISOC) and the 
Corporation for National Research Initiatives (CNRI). 


Any intellectual property rights of IETF protocol parameter 
assignment information, including the registry and its contents, and 
all registry publications, are to be held by the IETF Trust on behalf 
of the IETF. 


The IETF Trust may make such regulations as appropriate for the 
redistribution of assignment values and registry publications. 


2.5. Role of the IAOC 


The IAOC is responsible for identifying a potential vendor in a 
manner of their choosing, based on IAB consultation, and for managing 
the various aspects of the relationships with that vendor. 


In addition, the IAOC has the responsibility to ensure long-term 
access, stability, and uniqueness across all such registries. This 
responsibility is of particular significance in the event that a 
relation with a Protocol Parameter Registry Operator is terminated. 


3. Miscellaneous Considerations 


While this document has focused on the creation of protocols by the 
IETF, the requirements provided are generically applicable to the 
extended IETF community as well (e.g., Internet Research Task Force 
(IRTF)). 


The IESG is responsible for the technical direction of the IETF 
Protocol Parameter registries and maintaining the policies by which 
such technical directions are given. The IESG is responsible, as 
part of the document approval process associated with the IETF Stream 
RFCs [RFC4844], for "IANA Considerations" verification. For the 
other RFC streams, the approval bodies are responsible for verifying 
that the documents include "IANA Considerations" sections when 
needed, and that "IANA Considerations" sections conform to the 
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current published guidelines. In the case that IANA considerations 
in non-IETF document streams lead to a dispute, the IAB makes the 
final decision. 


This document talks about "Registry Operator" (singular), and while 
there are stability and economy-of-scale advantages for one single 
Operator, this document does not exclude having different Operators 
for different protocol registries when justified by the 
circumstances. 


4. Security Considerations 


This document does not propose any new protocols and does not 
introduce any new security considerations. 


5. IANA Considerations 


This document requires no direct IANA actions in terms of the 
creation or operation of a protocol parameter registry. However, 
this document does define the roles and responsibilities of various 
bodies who are responsible for, and associated with, the operation of 
protocol parameter registration functions for the IETF. 
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